Many of the UNIX operating systems of today support the generation of file identifiers for file system resources. A FID is a binary representation that uniquely defines a physical file system object that resides in a file system. The FID is typically a stream of bytes of arbitrary length that is commonly as small as eight to ten bytes in size. The contents of the FID bytes are often numerical in nature with the first set of bytes holding an index or “inode” number and the remaining bytes holding a generation or use instance of the inode.
Fids are used in present day operating systems for the implementation of network file sharing services. A file server process running on a file system server machine housing data will obtain a FID for a file when a client machine on a network searches for the file by name. The server will then return the FID to the client. The client sends the FID in subsequent requests to the server to perform operations on the file such as reading or writing data. The server uses the FID to quickly find the file system object's data structure and perform the operation. Thus in a network file system implementation, the FID acts as a alternate representation that can be quickly mapped to the object's defining data structure which often is a inode/vnode. Inode and vnode are used synonymously in this description. The vnode is an in-memory object that usually has a short lifetime and is frequently recycled for use by other accessed file objects. However the FID allows fast construction of a vnode for the unique physical file system object it describes.
The numerical nature, typically small size, and unique mapping to an individual file system object make the FID a powerful association tool. Given that the FID represents a single instantiation of an object, it also represents a unique mapping for any of the potential pathnames or alternate descriptors that can be used by an application to access the object. Thus a FID can be used as an efficient bi-directional mapping equivalent of file system object and any of its names.
FIDS are a powerful concept as their finite size and numeric nature make them suitable for efficient storage and searching. Once a FID is obtained through a file resource name to FID translation, it can be used to quickly obtain access to the actual underlying file system object data structures and access methods. The properties of FIDs make them useful in distributed file system server implementations for projecting a “file handle” out to client systems. The client can then provide the handle back to the server so it can quickly locate the associated resource's underlying data structure and perform operations requested by the client.
As has been mentioned, FIDS are beneficial in UNIX distributed file system implementations. Servers generate and provide FIDS to clients for use in subsequent transactions against the file resource corresponding to the FID. For example, writing data to the file. In the above example of /usr/local/bin/date, the client would first lookup the file by its name (/usr/local/bin/date) at the server. The server would return a FID for date along with other resource attributes for date. The client would then contact the server for additional operations providing the FID to the server. The FID allows the server to locate and operate on the underlying file resource much faster than if it had to process the file path name on each call from the client. If after accessing date, the client desired to create a new file called time in /usr/local/bin, it would first contact the server with the name /usr/local/bin to get the FID for bin. Next it would send another request to the server to create time in the directory bin using bin's FID. Situations like this where components higher up in a directory tree end up being accessed are actually common. One optimization in the above procedure would have been for the server to return the FIDS for all the components in the pathname leading to date as well as vi when the client first accessed /usr/local/bin/date by name at the server. This would have saved the server call to get the FID for /usr/local/bin. In a networked environment the savings could be significant. If there are other clients performing similar accesses to the server then even more calls are saved. Thus in the above example, the efficiency of the network file system protocol could potentially be improved by having the server return an array of FIDS for all the components along the file path provided in an initial client lookup request.
FIDS have other potential uses outside of network file system implementations as well. File resources in UNIX are represented in an inverted tree name space with the / character separating the components along the file path to the file resource. Each component represents a file system resource. The terminating component represents the target file resource of the path and the prior components represent a series of directories leading to the resource. For example, a path of /usr/local/bin/date specifies the path to the file resource named date which resides in the directory /usr/local/bin. The path contains four components with at least three of them being directories and the fourth terminating component (date) representing several possible file resource types. Resource types include directories, files, links, and special device files. The FID relationship exists at the individual file resource level. Thus in the example of /usr/local/bin/date, there are four associated FIDS.
FIDS have a unique one to one relationship to the physical file resources in a file system. In addition, the UNIX operating system can produce FIDs for the many forms of named or non-named methods an application program might use to access them. This property makes FIDS a good association tool for applying external attributes to file resources. One of the resource's well known names such as its full pathname starting at the file system root are used in a database of attributes which might be anything from extended information about the resource to rules describing additional security protections on the resource. Such a method is described in IBM Patent Application AUS9-2000-0672 titled “A Method for Attachment and Recognition of External Authorization Policy on UNIX File System Resources”. In the described methods security policy is placed on file resources using the full path name starting at the root of the file system. For example, /usr/local/bin/date. This name known as a protected object name (PON) is used as the name for locating the defined attributes. The PONs are then processed into their associated FIDs thus creating a mapping between the resource's FID and the defined external attributes. When file resources are accessed by applications, the file specification used in the access is converted into a FID, which can then be used to find the attributes in the external database.
An extension of those methods would be to traverse up the directory path of the resource towards the root of the file tree searching for components having attached attributes when the target of the access has no attached attributes. If an external attribute is found in the search, then it could be inherited and be treated as the effective attribute for the accessed file system resource. For both of the above examples, there exists an opportunity for operational improvement if an array of FIDS representing all the components along a file path to a file resource are available. To utilize this feature, methods that produce FIDS require techniques to create such an array of FIDS. The cost of producing an individual FID requires a lookup operation on the file system resource name. This lookup operation requires a relative degree of computational expense. Therefore techniques to produce such an array need to be efficient to minimize the performance impacts to the system. With efficient techniques and methods to produce a FID array, systems, which use FIDs in their processing, can exploit new mechanisms for more efficient operation or to support new features.